docs(env): describe the pytensor -> numba -> numpy chain by invariant - #77
Merged
Conversation
The comments on numpy, numba and pymc named pytensor 3.1.x, which is no longer what solves: pymc 6.2.0 pins pytensor-base >=3.2.2,<3.3, and every fresh solve now takes it — including this repo's own CI on main. The constraints themselves are unchanged and still correct. pytensor-base 3.2.2 caps numba at >=0.58,<=0.65.1, byte-identical to 3.1.3, and numba 0.65.1 still requires numpy <2.5. So the chain that justifies both caps survives the bump; only the prose was stale. Reworded to name the invariant rather than a version, so it stops going stale on the next pytensor minor, and to record that the pymc floor is the minimum supported rather than what installs. Specs are untouched: dse-check-env compares YAML-parsed values, which strip comments, so this needs no coordinated change in dependent repos and no release. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Note
Drafted by an LLM-based AI tool (Claude Code/Opus 5).
Comment-only correction to
environment-core.ymland this repo'senvironment.yml. No spec changes, no release, no downstream coordination.Why
Refreshing
vocabulary-growth's lock (dseinternational/vocabulary-growth#181) movedpymc6.1.0 → 6.2.0 andpytensor3.1.3 → 3.2.2. The floors already permitted that, so nothing broke — but three comments still named pytensor 3.1.x as the thing that produces the numba and numpy caps, and that is no longer what solves. This repo's own CI onmainnow builds againstpymc 6.2.0 / pytensor 3.2.2 / numba 0.65.1.The constraints are still correct — only the prose was stale
Verified against conda-forge metadata:
>=0.58,<=0.65.1>=0.58,<=0.65.1— identical>=1.22.3,<2.5pymc-base→pytensor-base>=3.1.2,<3.2>=3.2.2,<3.3The chain that justifies
numba>=0.58,<=0.65.1andnumpy>=2.4.6,<2.5survives the bump intact, so both caps stay exactly as they are. The cap also cannot be lifted yet: numba 0.66.0 exists but pytensor excludes it, and it still requires numpy<2.5.What changed
The comments now name the invariant rather than a version, so they stop going stale on the next pytensor minor:
numpy—pymc -> pytensor 3.x -> numba<=0.65.1 -> numpy<2.5numba— "every pytensor 3.x caps numba here (verified 3.1.3, 3.2.1, 3.2.2)"pymc— records that each pymc 6.x pins one pytensor 3.x minor, and that the floor is the minimum supported rather than what installs (6.2.0 / pytensor 3.2.2 currently)Why the pymc floor stays at 6.1.0
This file's convention is floor-as-minimum-supported, not floor-as-installed —
numpy>=2.4.6,arviz>=1.2.0and the rest all sit below what actually solves. Raising pymc alone would break that convention, cost a four-repo coordinated rollout plus a release, and buy nothing:language-reading-predictorsandus-birth-certificatescarry no lock files so they always solve fresh, andvocabulary-growth's lock was just refreshed to 6.2.0. Nothing in the fleet can land on 6.1.0 today.Why this needs no rollout or version bump
check_env_corecompares YAML-parsed values andyaml.safe_loadstrips#comments before the specs are read, so the canonical core is byte-identical as far asdse-check-envis concerned. Confirmed by parsing both revisions: the spec dictionaries are equal, with no diff. Dependent repos need no matching change and__version__stays at 0.8.0 — bumping would only invite a pointless re-pin in three repos.The same three comments are also mirrored in the dependent repos'
environment.ymlfiles and are stale there too. Harmless, and worth sweeping up in whichever PR next touches those files.🤖 Generated with Claude Code